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Abstract 

Radium is a new type of music editor inspired by 
the music tracker. Radium’s interface differs from 
the classical music tracker interface by using graphi¬ 
cal elements instead of text and by allowing musical 
events anywhere within a tracker line. 

Chapter 1: The classical music tracker interface 
and how Radium differs from it. Chapter 2: Ra¬ 
dium Features: a) The Editor; h) The Modular 
Mixer; c) Instruments and Audio Effects; d) In¬ 
strument Configuration; e) Common Music Nota¬ 
tion. Chapter 3: Implementation details: a) Paint¬ 
ing the Editor; b) Smooth Scrolling; c) Embed¬ 
ding Pure Data; d) Collecting Memory Garbage in 
C and C++. Chapter 4: Related software. 
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1 Introduction 

The tracker interface appeared on the AmigaOS 
platform in late 80s and early 90s with pro¬ 
grams such as Sonndtracker, NoiseTracker and 
Protracker. The first tracker was called 
“The Ultimate Sonndtracker”,^ and was re¬ 
leased in 1987 by Karsten Obarski.^ 

In the classical tracker interface, time goes 
downwards. Notes placed higher on the screen 
are played before notes placed below.^ Instead 
of moving the cursor up or down, the whole ed¬ 
itor scrolls up or down, and the cursor is just 
locked in the middle of the screen. 

The tracker editor shows a two-dimensional 
table in which musical events can be stored. We 
can think of it as a spreadsheet with tracks as 
columns and lines as rows. 

^According to Wikipedia: http://en.wikipedia.org/ 
wiki/Music_tracker 

^http://en.wikipedia.org/wiki/Ultimate_ 
Sonndtracker 

^When I started making radium, I also considered 
letting time go in the horizontal direction. I don’t re¬ 
member why I chose the vertical direction. 


Musical events are defined with pure text. 
The event C#3 5-32-000 plays the note C 
sharp at octave 3 using instrument number 5 at 
volume 32. The last three zeroes can be used 
for various types of sound effects, or to set new 
tempo. 

The tables are called patterns^ and a song 
usually contains several patterns. To control 
the order patterns are playbed back, we use a 
playlist For example, if we have three patterns, 
a typical song could have a playlist like this: 
1, 2, 1, 2, 3, 1, 2. 

1.1 How Radium Differs from the 
Classical Tracker Interface 

Radium^ differs from the music tracker inter¬ 
face by using graphical elements instead of text 
and by allowing any number of events to be 
placed anywhere.^ The latter means that a line 
in Radium is essentially just a graphical hint. It 
should be possible to compose millions of years 
of music within just one tracker line. 

These differences are so fundamental, that it’s 
questionable whether Radium can be defined as 
a tracker. 

1.2 History of Radium 

The first version of Radium was released in year 
2000 under the GPL license, and it only sup¬ 
ported MIDI. After the initial release, Radium 
was developed actively for around a year, fol¬ 
lowed by a period between 2001 and 2012 with 
less development. Since 2012, Radium has been 
actively developed again. 

The features presented in this paper have 
mostly been implemented in 2012 and 2013. 
Audio support was introduced in November 
2012 . 

^http://users.notam02.no/~kj etism/radium/ 

^This feature may not be useful, depending on how 
you compose music. But at least when using splitted 
lines, and for accurately importing midi files and other 
music formats, it’s a necessary feature. 



1.3 Portability 

The first version of Radium was released 
for the Amiga Operating System (AmigaOS)^ 
version 3.0 or later. The code was written in 
a portable style, where non-portable code was 
clearly separated and easy to replace. An alpha 
version for Linux was available already in 2001. 

Radium is at the time of writing available for 
Linux, Windows, and Mac OS X, where Linux 
is the main development platform and the plat¬ 
form with the most features. It should be 
straight forward to port Radium to a platform 
which has Jack, POSIX, and Qt. 

1.4 Term 

In the rest of this paper, the word “line” means 
a tracker line, and not a vertical graphical line 
(i.e. a row of pixels) or an automation line. 
In cases where we refer to a graphical line, 
the expression “graphical line” will be used in¬ 
stead. In cases where we refer to an automation 
line, the expression “automation line” or “break 
point line” will be used. 


2 Radium Features 
2.1 The Editor 

The image below shows a Block (the name of 
patterns in Radium).^ From left to right, we 
see a vertical slider, line numbers (12-29), a 
green and blue area indicating tempo, an LPB 
track (Lines Per Beat), a BPM track (Beats 
Per Minute), a RelTempo track (for doing time- 
varying tempo changes), plus two sound tracks; 
a drum loop track and a bass track: 



We also see that text is used to denote pitch 
(“D-4”, “D#3”, and “C-3”), while graphical 
break point lines are used to define tempo 
changes and effect automation. Pitch can be 

®The word “Block” comes from Octamed (http://en. 
Wikipedia.org/wiki/Octamed). I think Block is a better 
name than Pattern, at least in Radium where events can 
be placed freely and doesn’t have to follow a pattern. 


denoted with graphics too, using vertical lines, 
but text is clearer and more accurate. 

2.1.1 Editor Elements 

• Audio waveforms are shown in the tracks: 



• Time-varying volume changes 

(crescendo / diminuendo) are defined 

using break point curves. The audio 

waveforms are updated in realtime: 



• Time-varying tempo changes (ac- 
celerando/ritardando) are defined with 
break point lines. The audio waveforms 
are updated in real time: 
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• Effects, e.g. reverb or chorus, are also de¬ 
fined with break point lines: 



• ...And so are time-varying pitch changes 
(glissando’s): 
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• Pitch can be defined with unlimited preci¬ 
sion. The pitch below is placed 82 cents 
above C sharp at octave 4: 
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• Lines can be split. Splitting is essentially 
just a way to zoom in on one line so that 
you have more space to edit, but it can also 
be used to define measures. Furthermore, 
splitted lines can themselves be splitted, 
those lines again can also be splitted, and 
so forth: 
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a “diode” that lights up when receiving note 
events: 
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The green lines show connections for note 
events, such as Note On^ Note Off^ Note vol¬ 
ume changes, and Note pitch changes. 

The other connections (those painted in a 
color that resembles mortar^) show audio con¬ 
nections. 

2.2.1 Separate channel routing 


• Updating the graphics too often can be tir¬ 
ing for the eyes. The SPS option (Scrolls 
Per Second) sets a limitation on the num¬ 
ber of updates per second. SPS is an ef¬ 
fective way to make the viewing more plea¬ 
surable when not using smooth scrolling. 


s|w: 10 ! 


In the Mixer GUI, an audio connection sends 
all channels from one sound object to another. 
In order to (for instance) send only left channel, 
or only receive right channel, the audio connec¬ 
tions must be routed through special channel 
routing objects. 

The idea is that it’s faster to use a little bit 
more time to route channels separately when 
necessary, than to always connect every channel 
manually. 


• The velocity of new notes can be set using 
a random walk algorithm (drunk velocity). 
The algorithm tries to simulate how a mu¬ 
sician varies volume while playing: 


2.3 Instruments and Audio Effects 
2.3.1 Sampler Instrument 
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• All editing operations are undoable and re- 
doable. The number of undoes is limited 
by system memory. 

2.2 The Modular Mixer 

The modular mixer provides a graphical inter¬ 
face to route note events and audio signals be¬ 
tween sound objects. 

The role of a sound object is to produce audio, 
receive audio, produce note events, receive note 
events, or any combination of those. 

Inside each sound object in the Mixer GUI, 
there is a volume slider, a mute button, a bypass 
button, VU meters (one for each channel), and 


This instrument can play: 1) Normal sound- 
files,^ 2) Fasttracker instruments,^ or 3) Sound- 
fonts [Rossum and Joint, 1995]: 
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^“Name that color”: http://chir.ag/projects/ 

name-that-color/#594C5B 

®A11 formats supported by libsndfile: http://www. 
mega-nerd.com/libsndfile/ 

®Text files describing the Fasttracker 
“XI” instrument format: 1) “XI format description” by 
“KB / The Obsessed Maniacs / Reflex”, 2) “The XM 
module format description for XM files version $0104” 
by “Mr.H of Triton” in 1994. 















































2.3.2 VST Plugins and instruments 

Native VST plugins and instruments are sup¬ 
ported on Linux, OSX and Windows: 
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2.3.3 Pure Data (Pd) 

Pd processes can be inserted anywhere in the 
sound graph. The Pd GUI is opened by double 
clicking the sound object. There is no limitation 
on the number of simultaneous instances: 
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Custom Pd controllers make it possible to 
control Pd from Radium, and to control Ra¬ 
dium from Pd. The Pd controllers appear as 
Radium effects, similarly to “Max for Live”:^^ 



2.3.4 STK Instruments 

Radium includes 20 STK instruments doing 
physical modeling [Cook and Scavone, 1999]. 
These are written by Romain Michon in the 
Faust language [Michon and Smith, 2011]. 
Michon’s instruments have been slightly mod¬ 
ified to be used as instruments in Radium. 

^^https://www.ableton.com/en/live/max-for-live/ 


2.3.5 Zita Reverb 

Fons Adriaensen’s “Zita Revl” reverb {Zita Re¬ 
verb) implemented by Julius O. Smith III in 
Faust [Smith, 2012].^^ Zita Reverb is also 
used as the default reverb when creating a new 
song.^"^ 

2.3.6 Multiband Compressor 

A multiband compressor. The DSP is imple¬ 
mented in Faust by using components written 
by Julius O. Smith III [Smith, 2012].: Compres¬ 
sor, lookahead limiter, bandsplit, and smooth¬ 
ing. 

2.3.7 Other Instruments and Audio 
Effects 

a) LADSPA plugins. Richard Purse’s Linux Au¬ 
dio Developer’s Simple Plugin API. b) Maarten 
de Boer’s multitap delay “Tapiir” [De Boer, 
2001], implemented by Yann Orlarey in Faust, 
c) A Fluidsynth instrument, using libffu- 
idsynth.^^ d) Sound objects to send or receive 
audio to and from jack clients, e) A pipe ob¬ 
ject. f) Channel routing objects (section 2.2.1). 
g) MIDI output. 

2.4 Instrument and Plug-in 
Configuration Widget 

Sound goes through five parts in the instru¬ 
ment and plugin-in configuration widget. From 
left to right in the picture below, we see: 
1) A Note Duplieator^ 2) An automatically cre¬ 
ated Plugin/Instrument GUI, 3) A Compressor, 
4) An Equalizer, 5) Settings for dry/wet, pan¬ 
ning, stereo width, reverb, chorus, and output 
volume: 
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1) Instruments can play several note events 
when a note is played, using the note du- 
plieator. This is convenient to, for instance, 
double the bass, or add a simple echo. Up 
to six notes can be played for each incom¬ 
ing note event, and for each of those six 
notes, the user can specify values for transpo¬ 
sition, volume change, delay, and duration. If 

^^http://kokkinizita.linuxaudio.org/linuxaudio/ 
zita-revl-doc/quickguide.html 

^https://ccrma.stanford.edu/~jos/Reverb/Zita_Revl_ 
Reverberator.html 

^^The “Calf Multichoms” LADSPA plugin (written by 
Krzysztof Foltman) is used as the default Chorus effect. 

^“^http: //www. fluidsynth. org 


















































you need more than six notes, you can connect 
the sound object to yet another sound object to 
duplicate the notes further: 



2) Sliders and buttons are automatically created 
for all instruments and plug-ins, based on the 
controllers they provide: 
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3) The compressor has a novel interface which 
tries to show more intuitively how the sound is 
squashed together. The DSP code is written in 
Faust by Julius O. Smith III [Smith, 2012]. 



2.5 Common Music Notation 

Scores can be generated from Radium files 
automatically with Bill Schottstaedt’s nota¬ 
tion software Common Music Notation (CMN) 
[Schottstaedt, 1997].^^ The generated scores 
can be further tweaked in CMN, either by edit¬ 
ing the generated CMN code, or by writing code 
that further modifies the CMN code. The latter 


^^https://ccrma.stanford.edu/software/cmn/ 


technique is used to generate this score: 



3 Implementation Details 

Radium is mainly written in C and C-h+. Some 
code is also written in Python, Faust [Orlarey 
et ah, 2009] and Scheme. 

3.1 Painting the Editor 

The visible part of the editor is painted line 
by line to a backbuffer. When the editor is 
scrolling, we just copy corresponding tracker 
lines from the backbuffer into the screen. When 
a tracker line is not visible anymore, it is marked 
as free, and available for painting a new line. 
This way, we don’t have to repaint everything 
for every update or scroll the screen or the back- 
buffer. 

Unfortunately, this strategy causes the order 
of the lines in the backbuffer not to be chrono¬ 
logical (newer lines often appear below older 
lines). Non-chronological order makes it im¬ 
possible to paint graphical elements that span 
several lines in one operation. This limita¬ 
tion causes breakpoint boxes to be squashed 
up against the ceiling and floor of a tracker 
line,^^ and automation lines to be slightly not 
quite connected (or too much connected) be¬ 
cause of anti-aliasing artifacts.Scrolling the 
backbuffer^^ would not solve the problem either 
since graphical elements can start before the vis¬ 
ible area, or end after the visible area. There¬ 
fore, at least some graphical elements has to be 
painted in several operations anyway. 

An alternative solution that would solve the 
graphical problems, is to make the backbuffer 
big enough to contain the complete block. But 
this solution could occupy too much memory.^^ 

Using the Guile interpreter 
^^This effect probably looks more like a feature, 
^^while this effect probably looks more like a bug. 

^^or modifying Qt so that the underlying coordinate 
system would match the order of the lines in the back- 
buffer 

There are of course other solutions as well that would 
solve the graphical problems while still keeping the back- 
buffer, but I think they would complicate the code too 
much to be worth the effort. 




































However, since today’s desktop computers 
(2014) seems fast enough to just repaint the 
screen when necessary, the strategy of painting 
tracker lines one by one in a backbuffer will, al¬ 
beit so efficient that it made the program usable 
on hardware from 1992,^^ probably be removed 
in the near future. The advantage of not us¬ 
ing a custom backbuffer is simpler code and less 
graphical artifacts, plus that it is simpler to add 
new graphical features when graphical opera¬ 
tions are not bounded to be performed within 
tracker lines. 

3.2 Smooth scrolling 

Music trackers have traditionally updated the 
screen only when the current tracker line 
changes (i.e. scrolling line by line). By updat¬ 
ing the screen at each vertical blank instead, we 
get smooth scrolling. 

Smooth scrolling looks amazing compared to 
scrolling line by line, but perhaps more impor¬ 
tantly is that smooth scrolling seems signifi¬ 
cantly less tiring for the eyes. 

3.2.1 Render using the CPU 

The first attempt to achieve smooth scrolling 
was to make Radium render the screen by 
copying line by line from the backbuffer at 
each vertical blank. To achieve sub-pixel accu¬ 
racy, all painting operations on the backbuffer 
were performed n times, painting to n different 
back buffers, where each backbuffer was slightly 
skewed to the next one, all within the span of 
one pixel in the vertical direction. A good value 
for n would be at least 4. 

One problem with this attempt was that the 
amount of time to render a frame varied a bit, 
and it was easy to lose the vertical blank dead¬ 
line and get a frame glitch. The usual vertical 
blank period for an LCD screen is 16-h| ms, so 
we don’t have much time, and we can’t trust 
the OS to wake us up soon enough if the cur¬ 
rent process for some reason has yielded in the 
middle of rendering. 

A graphical glitch is very apparent when the 
whole screen moves in one direction at a con¬ 
stant speed, so to avoid frame glitches. Radium 
rendered frames in a separate thread and put 
them on a ringbuffer which the main thread 
would read from.^^ If a single frame took more 
time to render than 16-h| ms, we still avoided 

^^Amiga 1200 

^^This strategy is similar to how we reliably get sound 
in real time from a non-deterministic source, for instance 
a hard drive. 


a glitch if the average rendering time was less 
than 16-h| ms. 

However, this strategy didn’t play very well 
with the current painting system (i.e. the code 
became very complicated), plus that it had a 
quite high CPU usage (which also made it more 
prone to frame glitches), so it was abandoned. 

3.2.2 Render using the GPU 

A more successful attempt at achieving smooth 
scrolling has been to use OpenCL in 2D mode. 
By letting the GPU repaint everything at each 
vertical blank, we achieve both smooth scrolling 
and a very low CPU usage. Another advantage 
is significantly smaller and simpler code since 
we don’t use the type of backbuffer described in 
section 3.1 plus that scrolling is only a matter of 
sending updated y coordinates to OpenGL for 
the graphical objects. 

This code is currently under development and 
should replace the current system soon. 

3.3 Embedding Pd 

Radium uses Peter Brinkmann’s libpd‘^^ as basis 
to embed Pd. 

Libpd is a thin layer of code that makes Pd 
into a library [Brinkmann et ah, 2011]. Libpd 
doesn’t include the Pd GUI, and it has some 
other limitations as well, so a “Radium fork” 
of libpd has been made for including features 
needed by Radium. 

The first modification was to re-add the GUI 
and create an API to control it. Several other 
enhancements and required modifications fol¬ 
lowed, such as loading and saving patches and 
adding a void^ argument to the midi functions. 

3.3.1 Libpds (libpd with an extra ’s’) 

However, the biggest challenge for using libpd is 
that only one Pd instance can run in a process 
simultaneously. With only one instance, you 
can’t send sound from one patch to another in 
the Radium mixer (at least not if there is a non- 
pd sound object in the middle of those two). Or, 
for that matter, you can’t make a LADSPA or 
VST plugin out of a Pd patch. 

To circumvent this limitation, an additional 
library called libpds has been added to the Ra¬ 
dium fork of libpd. Libpds makes it possible 
to load several Pd instances and communicate 
with them separately. Libpds has almost the 
same API as libpd, except that most functions 
take an additional “pd instance” parameter. 

^^http://libpd.cc 

^^http://github.com/kmatheussen/libpd 



Libpds works by dynamically loading a new 
libpd library file for each new Pd instance. 
To avoid symbol clash for the global variables 
between the various Pd instances, dlopen is 
called with the RTLD.LOCAL flag when open¬ 
ing “libpd.so”. The RTLD_LOCAL flag pre¬ 
vents symbols from being shared globally. 

Unfortunately, this behavior causes problems 
when loading Pd externals (i.e. plugins which 
are loaded during runtime). Pd externals re¬ 
quire access to functions and global variables 
provided by Pd, but since Pd doesn’t share its 
symbols globally, the externals fail to load. 

The selected solution for the problem is to 
statically link the most common Pd exter¬ 
nals into libpd. 921 externals are currently 
included, and among them are most of the 
externals distributed with the Pd distribution 
Pd-Extended?^ In order to compile that many 
externals without manually writing a large 
Makefile, a script recursively scans a list of di¬ 
rectories and compiles all externals it can find. 

A slightly simpler way to load externals would 
be to link the Pd externals directly (i.e. instead 
of recompiling), but using a “.so” file as a static 
library does not work. 

It is likely that there are better ways to sup¬ 
port externals, such as implementing a new dy¬ 
namic linking system, but the current solution 
seems to work well for now 

3.4 Garbage collection 

Radium has from the start used Hans Boehm’s 
garbage collector for C and C++ as mem¬ 
ory manager (BDW-GC) [Boehm and Weiser, 
1988]. It is not necessary to free memory manu¬ 
ally when using a garbage collector, so Radium 
has fewer lines of code, and most likely fewer 
bugs, because of this choice. 

There has been no trouble with BDW-GC, 
and Radium has not had memory leaks. It is 
strange that BDW-GC is not used in most large 
programs written for C or C++. 

4 Related software and how their 
features compare to Radium 

4.1 Jeskola Buzz 

Jeskola Buzz‘^^ appeared in 1997-1998.^^ 
Jeskola Buzz was probably the first tracker 
with a modular mixer. The modular mixer in 
Radium is inspired by the one in Jeskola Buzz, 

^^http://puredata.info/downloads/pd-extended 
°http://www.j eskola.net/buzz/ 

'^http: //en. wikipedia. org/wiki/Jeskola_Buzz 


but the modular mixer in Jeskola Buzz doesn’t 
support sending note events or sound objects 
with more than two channels. 

4.2 Aodix 

Aodix‘^^ was released before 2002, but I don’t 
know when. Aodix may have been the first 
tickless tracker, depending on how old Aodix 
is. Tickless means that events are not bounded 
by tracker lines, a feature which is shared with 
Radium. Another feature shared with Radium 
is that you can apparently zoom in and out of 
the patterns. 

4.3 Renoise 

Renoise‘^^ was released in 2002. Renoise is a 
more traditional tracker than Jeskola Buzz and 
Aodix, but has more features. 

Renoise uses one instrument per track, which 
is similar to Radium, but Renoise lets you orga¬ 
nize tracks further by optionally grouping tracks 
and instruments. For instance by grouping all 
drum tracks or all vocal tracks. Grouping makes 
patterns visually clearer and simpler to navi¬ 
gate and it simplifies adding effects to a group 
of instruments (since they are already grouped). 
Grouping is a feature that is currently missing 
in Radium. 

Renoise also supports effect automation and 
tempo automation, but unlike Radium, the 
graphics is placed horizontally in a separate area 
below the tracks, and not in the tracks them¬ 
selves. 

5 Conclusion 

Radium presented a radical change to the clas¬ 
sical tracker interface when it was released four¬ 
teen years ago. 

The following is a list of larger tracker fea¬ 
tures that first appeared in Radium (at least 
to my knowledge). An appending * means that 
Radium is still the only tracker, or tracker-like, 
program that provides this feature, at least to 
my knowledge: 

o) Smooth scrolling*; b) Limitation on the number of scrolls 
per second*; c) Tickless timing (may have been introduced 
in Aodix before Radium); d) Zoom in/out (may have been 
introduced in Aodix before Radium); e) Waveform data 
visible in tracks; f) The “Radium Compressor” compres¬ 
sor interface*; g) Pitch values shown graphically; h) Tempo 
automation*; i) Effect automation*; j) Volume automation*; 

^^http://WWW.kvraudio.com/product/ 
aodix-by-arguru-software/details 

^http://www.renoise.com 



k) Pitch automation*; 1) Adjustable track widths*; m) Pd 
or Max/MSP integration*; n) Track headers with volume 
control and instrument name*; o) Automatic MIDI pre¬ 
set change when playing note for instrument with different 
preset*; p) Line splitting (including line split splitting, line 
split split splitting, etc.)*; q) Unlimited number of simulta¬ 
neously playing notes per track, and no limitation when they 
are allowed to start and stop playing*;^® r) Unlimited num¬ 
ber of blocks, tracks and lines; s) Generate scores with CMN*; 
t) Unlimited undo/redo; u) Send pitch change events between 
instruments*;^^ v) Configurable menus*. 

This list of (more or less useful) new features 
shows that Radium has tried to be an innovator 
for tracker software. Radium will try to be an 
innovator in the future as well. 
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Roche: Memory barrier code; Gary P. Scavone: RtMidi; 
Bill Schottstaedt: CMN; Julius O. Smith HI: Compressors / 
lookahead limiter / filters / equalizer; Hans-Christoph Steiner 
et ah: Pd-Extended; www.magnetophon.nl: The included 
Blowfish demo song; TumaGonx Zakkum: LADSPA plugins 
for Windows. 

I also want to especially thank Yann Orlarey 
for creating the Faust programming language 

^^I.e polyhponic aftertouch for pitch instead of volume 


and Julius O. Smith III for all the DSP code 
he has written for Faust. Their work has saved 
me a lot of time and ensured professional sound 
quality. 
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